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(54) Method for adapting mobile terminals to different protocols and mobile terminal 



(57) A method for adapting mobile terminals in wire- 
less communication systems to the variety of different 
protocols used when interacting with a multitude of dif- 
ferent service providers. By using a set of building 
blocks, so called "primitives" stored in the terminal in- 
stead of having a set of protocols stored, a script is 



FIG.l 



downloaded from a service provider with instructions 
how the primitives should be arranged to form the de- 
sired protocol. The service provider secures his identity 
with a digital signature to ensure a correct operation. 
Preferably, the script is executed in one atomic opera- 
tion. Preferably, the script forms a protocol adapted for 
money transactions. 
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Description 

TECHNICAL FIELD OF THE INVENTION 

[0001] The present invention relates to a method for, 
and to a mobile terminal for, adapting mobile transceiv- 
ing terminals in a wireless communication system to a 
variety of different protocols in a secure manner. 

DESCRIPTION OF RELATED ART 

[0002] In the emerging mobile electronic commerce, 
there is a need for implementing secure protocols for 
payments, tickets or other sensitive data. Today, a vast 
number of different protocols are used for similar appli- 
cations. They have emerged from different industries as 
well as from different geographical areas. 
[0003] Since the market for e-commerce still is so im- 
mature, it is likely to create a variety of new protocols 
over time. To cope with such an amount of protocols dif- 
ferent solutions could be imagined and has also been 
proposed. 

[0004] Until now, state of the art technique has pro- 
posed several alternatives to handle the large amount 
of different protocols. One solution has been to build in 
a subset of protocols in each mobile phone. This is not 
very successful since the numbers of protocols are too 
large to be implemented. Memory space in not an end- 
less resource, especially not in mobile handsets when 
compared to PCs, and by this technique a lot of valuable 
memory will be used for services never wanted by the 
customer and also certain services that might be wanted 
has never been implemented. Also new protocols de- 
fined after the production of the mobile terminal can not 
be introduced. 

[0005] Yet another problem is to deal with limited va- 
lidity period of a protocol in a terminal. It also requires 
each service provider to evaluate and agree upon each 
step in production of the terminal to ensure the security 
of the implementation in each product. 
[0006] Another solution would be to create an open 
area for application download. Unfortunately, the secu- 
rity may then be compromised due to viruses, false ap- 
plications etc. downloaded to the mobile terminal. In the 
PC world of today, this is a very well known problem. 
[0007] Yet another solution would be to build in proto- 
cols in an external device which could be used by the 
mobile terminal to download from. The obvious disad- 
vantage with this method would be that your mobile ter- 
minal (commonly a mobile phone) will no longer be the 
center of mobile e-commerce. it would also require the 
user to carry around several gadgets and limit the 
number of users since not all mobile users are likely to 
have the extra device needed. The marginal costs would 
also be higher then compared to if it were implemented 
in an existing product like the mobile phone. An example 
of a product connected with this technique would be the 
"wireless wallet". 



[0008] Still another technique that could be conven- 
ient would be to define a common mobile electronic 
transaction protocol. This seems hard to realize since 
that would require all industries using mobile transac- 
5 tions to agree on one single protocol. It would still not 
solve the problem with dynamic upgrades as a new ver- 
sion of the protocol is introduced. This would also re- 
quire changes in existing infrastructure to accept the 
new protocol. 

w [0009] Therefore it would be desirable to be able to 
dynamically update the support for different protocols in 
individual terminals whilst preserving the high degree of 
security needed for electronic transactions. 

15 SUMMARY 

[0010] It is an object of the present invention to over- 
come the above mentioned problems and provide a 
method for adapting mobile terminals to different proto- 
cols in a wireless communication system overcoming all 
the above mentioned problems. 
[001 1 ] Another object of the present invention is to ar- 
range for a transaction with full security and for which 
the user feels comfortable and safe when using. 
[0012] According to one aspect of the present inven- 
tion there is provided a method that enables a dynamical 
updating for different protocols as claimed in claim 1 . 
[0013] Instead of storing an excessive number of pro- 
tocols in your mobile terminal, the idea underlying this 
invention is to store a number of primitives that, when 
put together, could form a script language in the termi- 
nal. The primitives could be characterized as the "build- 
ing blocks" of the script language, i.e. the smallest iden- 
tifiable units. The script language should then be used 
to form "scripts" that are able to describe a number of 
different protocols. A script could therefore be said to 
describe a selection of primitives following each other 
in a certain order to form a protocol. 
[0014] These protocols should not be understood as 
restricted to mobile electronic transaction protocols 
even though such protocols will be used as example un- 
der the detailed descriptions. 
[0015] The basic idea however, on which the inven- 
tion relies, is that the primitives (building blocks) forming 
the protocols will have a longer lifetime themselves than 
the protocols they form. Protocols of today come and 
go, but their smallest units are often the same, arranged 
together in different orders. By securing the implemen- 
tation of the primitives, different protocols can be utilized 
and thereby making the production of terminals less de- 
pendent of the service provisioning. 
[001 6] The script is preferably defined by a content or 
a service provider (such as VISA, AM EX or the local 
Certification Authority), which ensures that the script is 
to be trusted and that the protocol is valid. 
[0017] To arrange for a transaction with full security 
the script is signed by a digital signature to ensure that 
no changes are made from the original definition of the 
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protocol. The signature will then be verified and the 
script executed in the terminal in a way that guarantees 
that the script is executed in one atomic operation by 
the calling application with the exact flow intended by 
the signer of the script. 5 
[0018] A transaction method according to the inven- 
tion thereby entails a number of advantages, e.g; 
[0019] When you need to update a protocol you just 
have to update which primitives to use and in which or- 
der they should follow each other. 
[0020] The primitives used are more stable over time 
than the more complex protocols built on top of them. 
[0021] Implementations according to the invention al- 
lows dynamic download of complex protocols with full 
security and also automatically indicates to the user who 
is the issuer and are to be trusted. 
[0022] The specific implementation in a given terminal 
can be hidden. If for example the protocol requires en- 
cryption based on minimum 64 bits, this can be imple- 
mented as for example SSL or WTLS in the transport 
layer. This would be transparent to the calling applica- 
tion as long as the encryption is supported by the termi- 
nal with at least the requested quality. Therefore neither 
the user, nor the service provider have to bother about 
hardware and software implementations in each termi- 
nal product to be used, implementation dependencies 
irrelevant to the security are hidden in the primitives. 
[0023] The primitives can be used to build any secure 
protocol, i.e. not limited to payments or tickets, as long 
as they can be described by a sequence of primitives. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0024] The features of the invention believed to be 
novel are set forth with particularity in the appended 
claims. The invention itself however, both as to organi- 
zation and method of operation, together with further ob- 
jects and advantages thereof, may be best understood 
by reference to the following description with the accom- 
panying drawings, in the several Figures in which: 

Fig. 1 shows a block diagram depicting the basic 
structure and 

Fig. 2 shows a block diagram depicting a flow chart 
describing a preferred embodiment of the invention. 

DETAILED DESCRIPTION OF EMBODIMENTS 

[0025] In a preferred embodiment of the invention il- 
lustrated in Fig. 1 a set of primitives should be preloaded 
in a mobile terminal (e.g. mobile phone, smart phone or 
any computerized product with transceiving capability). 
These primitives could be simple commands that when 
put together form a script language. 
[0026] Examples of such primitives are "Sign text" , 
"Verify signature" or "Store copy protected". The primi- 
tives could also be mathematical algorithms or different 



transactions towards a safe storage area on the phone, 
e.g. the SIM-card. Also primitives such as "If.. Then", 
"While ... Do" are needed for flow control. By giving the 
primitives "labels", true identification standardization of 
the different primitives are ensured. 
[0027] The script language is able to give a descrip- 
tion for the primitives, in which order they should follow 
and how they should interconnect. It could also state the 
minimum quality required by each operation, (e.g. the 
key length needed for the encryption, whether personal 
keys/certificates need to come from smart cards or if a 
simple certificate in the RAM is enough) 
[0028] The script language is then able to describe a 
number of different protocols. Such protocols could as- 
sist a user to perform a variety of services, e.g. mobile 
electronic transactions. Some scripts could be preload- 
ed in the telephone, but the main advantage is evidently 
that a dynamical downloading of the script could take 
place when a user wants to start a certain application/ 
transaction. The calling application will then just have to 
download the script needed for performing its task. 
[0029] The script, which is defined by a company that 
acts as the service provider, should be signed with a dig- 
ital signature to ensure that no changes are made from 
the original definition of the protocol. 
[0030] This could e.g. be implemented so that a digital 
signature production part produces the digital signature 
using a secret key of the service provider which normally 
enciphers the data using an asymmetrical encipherment 
algorithm operating under both the secret and a public 
key. The digital signature is then added to the transmit- 
ting data of the script and is then transmitted to the mo- 
bile terminal. It can be deciphered using a complemen- 
tary public key. 

[0031] In that way the signature would be verified by 
the user and the script executed in the terminal as one 
atomic operation by the calling application. This ensures 
that the signer of the script, i.e. the company that acts 
as a service provider for the application, executes the 
script with the exact flow as intended. Hence it is very 
important that the script is not interrupted and that the 
user knows he is in contact with the service provider so 
there are no intermediate forgers. 
[0032] The verification could be used as a criterion for 
displaying a security icon on the terminal. In that manner 
the user will be sure that a secure and correct operation 
is now available. The icon could e.g. be linked to the 
trademark of the company issuing/guaranteeing/signing 
the protocol, e.g. VISA or any other content provider. 
The user is thereby informed that he is using a secure 
service and at the same time gets the verification of the 
content/payment provider. In this way no additional 
steps are needed from the user to get this verification. 
It also protects the service provider from false imple- 
mentations. 

[0033] Turning now to Fig. 1 , the process is illustrated 
with an exemplary digital packet 1 , containing informa- 
tion both about the script 2 and the digital signature 3. 
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This is just one example of a packet which could be 
downloaded to the mobile terminal from a service pro- 
vider and the general concept of the invention is not to 
be restricted to any forms and kinds of digital packets. 
[0034] The downloaded script 2 could be described 
as a recipe for creating a protocol out of primitives A-D. 
One of the primitives 4 could e.g. be the command "Ver- 
ify signature". The engine running the script on the ter- 
minal could be certified to a certain capability of level 
and trust using code verification or other security mech- 
anisms. Box 5 illustrates a secure storage for the prim- 
itives in the mobile terminal where access is only al- 
lowed after correct verification of the digital signature. 
By saying that the primitives should be stored in the mo- 
bile terminal, it is also implied that this could mean that 
they are stored on the SIM-card. Having them stored in 
the mobile terminal, (e.g. in a memory or on the SIM- 
card) is advantageous, but even having them stored in 
an external unit could be imaginable. 
[0035] Box 6-8 represents three different protocols 
from three different imaginary service providers, where 
we see that the content of each protocol could differ in 
that the order of the primitives in each protocol differ. 
[0036] Each primitive can be implemented in a variety 
of ways but the application can request a certain quality 
of service. For example that the certificate is stored on 
a smart card, that memory is copy protected, that the 
keyboard is tamper proof etc. Hence, the service quality 
requirements is decided by the application and secured 
by the digital signature. Each primitive and service qual- 
ity level can be registered to indicate to an application 
on a higher level what options are available in a specific 
terminal at any given time. 

[0037] A real case scenario example is presented in 
fig. 2; 

[0038] A user 11 wants to perform a money transac- 
tion from one of his accounts to another. A mobile ter- 
minal 1 3 is used to connect to a server, e.g. via a WAP- 
browser 14. The server is under control of the service 
provider 12 (e.g. VISA). He selects the desired payment 
action 1 5 (here e.g. "transfer between own accounts") 
and sends a payment request to the service provider. 
The service provider determines what payment protocol 
is appropriate 1 6 and asks whether the protocol needed 
is already downloaded 1 7. The application checks if you 
already have the selected protocol, 
i.e. if you are already a VISA customer. If not, the user 
can request a download of the protocol, whereby the 
service provider prepares the script, signs it and en- 
crypts it with a private key 18. The script is then down- 
loaded and the mobile terminal verifies and stores it 1 9. 
[0039] The script is now ready for execution and that 
could start with a verification of the service provider sig- 
nature 20 by using a public key according to any known 
technique. If verification is positive, the application could 
be set to display an icon, e.g. the Visa logo on the 
screen, to inform the user that it is a safe connection. 
[0040] It could e.g. also be checked here that the prim- 



itives used are primitives known by the mobile terminal 
so that the script is valid with reference to what the mo- 
bile terminal is prepared for. 

[0041] The script could then e.g. include controlling of 
5 a PIN code 21 ,22 connected the user and, when con- 
sidered ok by the service provider, allows the user to 
prepare the transaction 23. The user enters into his mo- 
bile terminal the transaction data (amount, account 
number etc.). 

10 [0042] The transaction is signed 24 by the user using 
a private key and is sent 25 encrypted to the service 
provider. The transaction is now completed and the Vi- 
sa-icon could be switched off 26. 
[0043] This flowchart is merely imaginary exactly in 
15 what order commands are given and the stepwise pro- 
cedures are executed. Variations in said flowchart lie 
within the scope of the invention and are only a simple 
software implementation design matter. 
[0044] During the procedure and invisible to the user 
20 of the mobile terminal, the description of the protocol, 
the script, is downloaded. As mentioned above, the mo- 
bile terminal checks the digital signature according to 
any known technique by e.g. downloading a certificate 
or having a key already stored. 



Claims 

1. Method for adapting mobile terminals to different 
30 protocols in a wireless communication system 
characterized in that it enables a dynamical up- 
dating or downloading of different protocols by; 



defining a script language made of primitives, 
35 the script language being able to describe a va- 

riety of protocols, said primitives being stored 
in the mobile terminal 

downloading a script from a service provider in- 
to a mobile terminal, said script defining the or- 
40 der in which the primitives are to be executed, 

thus forming a protocol, 
executing said script in said mobile terminal. 

2. Method for adapting mobile terminals to different 
45 protocols in a wireless communication system ac- 
cording to claim 1 , cha racterized in that the service 
provider signs the script with a digital signature be- 
fore the downloading into the mobile terminal. 

so 3. Method for adapting mobile terminals to different 
protocols in a wireless communication system ac- 
cording to claim 2, cha racterized in that the execu- 
tion of the script starts with a verification of said 
service provider signature. 

55 

4. Method for adapting mobile terminals to different 
protocols in a wireless communication system ac- 
cording to claim 2 or 3, characterized in that the 
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service provider signs the script using a private key 
and that the user verifies said signature using a pub- 
lic key. 

5. Method for adapting mobile terminals to different s 
protocols in a wireless communication system ac- 
cording to any of claims 2 to 4, 

characterized in that a correct verification is used 
as a criteria for displaying a security icon on the dis- 
play of the mobile terminal. 10 

6. Method for adapting mobile terminals to different 
protocols in a wireless communication system ac- 
cording to any of claims 1 to 5, characterized in 
that the script is executed in one atomic operation 15 
by the calling application. 

7. Method for adapting mobile terminals to different 
protocols in a wireless communication system ac- 
cording to any of claims 2 to 6, characterized in 20 
that the calling application can request a certain 
quality of service level which will be secured by the 
digital signature. 

8. Method for adapting mobile terminals to different 25 
protocols in a wireless communication system ac- 
cording to any of claims 1 to 7, characterized in 
that the downloaded script forms a protocol adapt- 
ed for money transactions. 

30 

9. A mobile terminal used in a wireless communication 
system adapted to different protocols character- 
ized in that it enables a dynamical updating or 
downloading of different protocols by storing a set 

of primitives, said primitives defining a script Ian- 35 
guage being able to describe a variety of protocols 
and comprising; 

means for downloading a script from a service 
provider, said script defining the order in which *o 
the primitives are to be executed, thus forming 
a protocol and 

means for executing said script. 
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